Skip to content

fix(trainer): ignore PEP 668 system python check#384

Merged
google-oss-prow[bot] merged 1 commit intokubeflow:mainfrom
robert-bell:fix-pep-668
Mar 13, 2026
Merged

fix(trainer): ignore PEP 668 system python check#384
google-oss-prow[bot] merged 1 commit intokubeflow:mainfrom
robert-bell:fix-pep-668

Conversation

@robert-bell
Copy link
Contributor

What this PR does / why we need it:

The pytorch/pytorch:2.10.0-cuda12.8-cudnn9-runtime image brought in by kubeflow/trainer#3320 has PEP 668 enabled which causes pip install to fail when creating custom train jobs, causing the trainjob to fail.

Generally, it sounds like python images shouldn't be enabling PEP 668, but I think it's a good idea for us to explicitly disable the check whenever we're creating jobs in a container.

Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):

Checklist:

  • Docs included if any changes are user facing

Copilot AI review requested due to automatic review settings March 13, 2026 16:33
@github-actions
Copy link
Contributor

🎉 Welcome to the Kubeflow SDK! 🎉

Thanks for opening your first PR! We're happy to have you as part of our community 🚀

Here's what happens next:

  • If you haven't already, please check out our Contributing Guide for repo-specific guidelines and the Kubeflow Contributor Guide for general community standards
  • Our team will review your PR soon! cc @kubeflow/kubeflow-sdk-team

Join the community:

Feel free to ask questions in the comments if you need any help or clarification!
Thanks again for contributing to Kubeflow! 🙏

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request adds PIP_BREAK_SYSTEM_PACKAGES=1 environment variable to pip install commands in the Kubeflow Trainer SDK. This fix enables Python package installation in Python 3.11+ externally managed environments (like Debian/Ubuntu system Python) where pip otherwise refuses to install packages without explicit permission.

Changes:

  • Add PIP_BREAK_SYSTEM_PACKAGES=1 flag to pip install commands in Kubernetes backend
  • Update all test expectations in Kubernetes backend tests to reflect the new pip command format
  • Add PIP_BREAK_SYSTEM_PACKAGES=1 flag to pip install commands in Container backend

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
kubeflow/trainer/backends/kubernetes/utils.py Updated two pip install command invocations to include PIP_BREAK_SYSTEM_PACKAGES=1 flag
kubeflow/trainer/backends/kubernetes/utils_test.py Updated 10 test assertion lines across 5 test cases to expect the new pip command format
kubeflow/trainer/backends/container/utils.py Updated pip install command builder function to include PIP_BREAK_SYSTEM_PACKAGES=1 flag

Comment on lines +297 to +300
if PIP_DISABLE_PIP_VERSION_CHECK=1 PIP_BREAK_SYSTEM_PACKAGES=1 python -m pip install --quiet \\
--no-warn-script-location $PIP_OPTS --user $PACKAGES >"$LOG_FILE" 2>&1; then
echo "Successfully installed Python packages: $PACKAGES"
elif PIP_DISABLE_PIP_VERSION_CHECK=1 python -m pip install --quiet \\
elif PIP_DISABLE_PIP_VERSION_CHECK=1 PIP_BREAK_SYSTEM_PACKAGES=1 python -m pip install --quiet \\
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flag should not be added to the localprocess backend. It is not safe to install packages into the system python outside containerised environments, and it's not necessary as this backend uses a venv.

rm -f "$LOG_FILE"

if PIP_DISABLE_PIP_VERSION_CHECK=1 python -m pip install --quiet \\
if PIP_DISABLE_PIP_VERSION_CHECK=1 PIP_BREAK_SYSTEM_PACKAGES=1 python -m pip install --quiet \\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am wondering if PIP_BREAK_SYSTEM_PACKAGES can break other user's deployment.
WDYT @kubeflow/kubeflow-sdk-team ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be a safe default given it's only set in a container. It just means that pip doesn't complain if it tries to modify an externally-managed python. It doesn't change how pip installs the packages.

Signed-off-by: Rob Bell <robell@redhat.com>
@andreyvelich
Copy link
Member

/ok-to-test

Copy link
Contributor

@astefanutti astefanutti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @robert-bell!

/lgtm

Copy link
Member

@andreyvelich andreyvelich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@google-oss-prow
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-prow google-oss-prow bot merged commit a0446d5 into kubeflow:main Mar 13, 2026
19 checks passed
@google-oss-prow google-oss-prow bot added this to the v0.4 milestone Mar 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants